MPC Wallets

Overview

Crypto wallets are designed to store your private key, keeping your crypto accessible at all times. They also allow you to send, receive, and spend cryptocurrencies like Bitcoin and Ethereum. Cryptocurrency wallets can be categorized based on whether they are cold or hot, by key management approach are they custodial or non-custodial, and by specific technologies such as Multisig or MPC wallets. Custodial wallets mean a third party (e.g., an exchange) controls the private keys, while non-custodial wallets give the user full control over the keys.

We research all these types with focus on the design and structure of the Multi-Party Computation (MPC) wallets and analyzing a range of algorithms, each employing distinct methods for key generation, distribution, and reconstruction. Collectively, these algorithms address the core requirements of MPC wallets: secure key distribution, resilience against compromise, and operational efficiency.

Cold Wallets

Cold wallets store private keys offline, providing a high level of security for long-term cryptocurrency storage. They are almost always non-custodial, as the user controls the keys, though rare cases may involve a third party in cold storage.

1. Physical Cold Wallets:

1.1. Paper Wallets: Private and public keys printed on paper, often as QR codes. Always non-custodial, as the user generates and stores the keys. They operate offline and support BIP-38 encryption for additional password protection. They are characterized by high security against online attacks. The main disadvantage is their susceptibility to physical damage or loss and impracticality for frequent transactions.

1.2. Physical Wallets: Private key engraved on durable materials (e.g., metal plates, coins). Similar to paper wallets but more durable. Always non-custodial, as the user possesses the physical object with the key. The main disadvantage is that they are expensive and require secure storage.

2. Digital Cold Wallets:

2.1. Hardware Wallets: Physical devices that store private keys on a secure chip, isolated from the internet. Always non-custodial, as the user controls the device and keys. Key characteristics include support for BIP-39 mnemonic phrases, PIN protection, and offline transaction signing. They are characterized by high security and practicality for use. The main disadvantage is their cost and potential for loss or damage.

2.2. Offline Software Wallets: Software wallets on a device not connected to the internet (e.g., a computer or USB). Always non-custodial, as the user manages the device and keys. They function as cold wallets if the device remains offline. The advantage is that they are free and flexible, while the disadvantage is that they require technical knowledge for secure setup.

2.3. MPC Cold Wallets: Private key shards stored on offline devices using Multi-Party Computation (MPC). Typically non-custodial, but can be custodial if a third party (e.g., an institution) holds a key shard on an offline server. The key is split into shards, and signing occurs without revealing the full key. They offer high security and eliminate single points of failure. Complex setup and potential need for coordination are the main disadvantages.

Hot Wallets

Hot wallets are connected to the internet, making them convenient for daily transactions but less secure. They can be custodial (the exchange controls the keys) or non-custodial (the user controls the keys).

1. Desktop Wallets: Programs installed on an internet-connected computer. Typically non-custodial, as the user controls the keys on their device. Private keys are stored on the device and are suitable for regular transactions. They are free and easy to use. The main disadvantage is their vulnerability to malware if the computer is not secured.

2. Mobile Wallets: Applications on smartphones for managing cryptocurrencies. Typically non-custodial, but some apps may be custodial if linked to an exchange (e.g., Coinbase). They are convenient for mobile transactions, making them accessible anywhere and easy to use.

3. Web Wallets: Wallets accessible via a browser, often integrated with exchanges. Often custodial, where the exchange controls the keys, but non-custodial options exist. They are accessible from any device; custodial versions depend on the exchange's security. They are highly convenient and easy to access. However, custodial wallets risk loss of control over keys, and non-custodial ones are susceptible to phishing.

4. MPC Hot Wallets: In MPC-based wallets, private keys are divided into multiple cryptographic shards and stored on separate online devices. This architecture enables secure off-chain transaction signing without ever reconstructing the full private key. MPC wallets can be non-custodial, where the user controls at least one key shard, or custodial, where entities like exchanges retain custody of all shards. Compared to standard hot wallets MPC wallets offer enhanced security by eliminating single points of failure and improved privacy, since the full key is never exposed. However, they introduce additional complexity in setup and operation. Coordinating multiple parties for shard management and signature generation can lead to increased latency and operational overhead, particularly in real-time or high-frequency use cases.

Multisignature (Multisig) Wallets

Multisignature (multisig) wallets are a type of cryptocurrency wallet that require multiple private keys to approve and authorize a transaction. For example, a 2-of-3 configuration means that any two out of three authorized keys must sign a transaction for it to be considered valid. These wallets are generally non-custodial, with users or teams managing their own keys. However, some institutional services may be custodial if a third party holds one of the keys. Private keys in a multisig setup are stored on separate devices or in different physical locations, which can be either hot (online) or cold (offline). This structure significantly reduces the risk of theft, since compromising a single key is not enough to access the funds.

Despite their security advantages, multisig wallets can be complex to set up, and key recovery can be difficult, especially if the required number of keys is lost or becomes inaccessible. Additionally, depending on the blockchain, multisig transactions may be less private, as their structure and participants can often be identified on-chain. A key limitation of traditional multisig systems is the lack of native support for key refresh or rotation. If a key needs to be changed due to loss, compromise, or changes in access control, the entire multisig wallet often must be redeployed with a new address. This process requires coordination among signers, incurs on-chain costs, and can publicly expose changes in wallet structure or ownership. Despite these challenges, multisig wallets remain a well-established and widely adopted method for securing digital assets through shared control and redundancy, particularly well-suited for collaborative or organizational environments.

Multi-Party Computation (MPC) Wallets

MPC wallets use Multi-Party Computation to distribute a private key into shards among multiple parties, enabling signing without revealing the full key. They can be both custodial and non-custodial. In non-custodial setups, the user controls at least one key shard. In custodial setups, a third party (e.g., an exchange or institutional provider) holds some key shards. They can be cold (offline shards) or hot (online shards); off-chain signing enhances privacy and reduces costs.

In an MPC wallet, the private key is split into encrypted shards, which are stored separately (e.g., on a user's device, a server, or a hardware wallet). When a transaction needs to be signed, the parties perform a collaborative computation using their respective shards, generating a signature without revealing the full key or individual shards. This process occurs off-chain, ensuring privacy and reducing blockchain fees. MPC protocols, such as threshold cryptography, allow flexibility in defining how many shards (e.g., 2-of-3) are required to authorize a transaction.

The primary purpose of MPC wallets is to provide enhanced security and privacy for cryptocurrency storage and transactions. By distributing the private key, they eliminate the risk associated with a single compromised key, making them ideal for both individual users and institutions managing large crypto assets. They are particularly valuable in scenarios requiring trustless key management, such as institutional custody, DeFi applications, or collaborative fund management, where multiple parties need to approve transactions without exposing sensitive data.

MPC wallets offer significant advantages, including the elimination of single points of failure since no single party holds the full private key, ensuring enhanced security. They provide high privacy as key shards remain encrypted during computations, protecting sensitive data. Additionally, MPC wallets allow flexibility in configuring the number of parties or devices required for signing, making them adaptable to various use cases. They are also cost-efficient due to off-chain signing, which reduces blockchain transaction fees. However, MPC wallets come with challenges, such as a complex setup that requires technical expertise or coordination between parties, potentially leading to slower signing processes due to the need for shard coordination. Furthermore, they may face occasional incompatibility with standard wallets that do not support MPC protocols.

History of MPC Wallets

Multiparty Computation (MPC) has its roots in academic research dating back to the 1980s. It emerged from the desire to compute functions over private data without revealing it. Here's how it evolved into a critical cryptographic primitive in blockchain:

• 1982-1990s: Yao's Garbled Circuits and early theoretical work on secure multiparty protocols.

• 2000s: Threshold cryptography becomes usable, yet remains academic.

• 2015-2020: Fireblocks, Curv (later acquired by PayPal), and ZenGo bring MPC wallets to real-world applications.

• 2021-2023: Growth of Web3 leads to centralized-MPC dominance in custodial and institutional wallets.

• 2024-Present: Decentralized MPC networks emerge (Lit Protocol, Odsy/dWallet, ContinuumDAO) as a response to centralization and single-point-of-failure limitations.

The user wallet is also tasked with safely storing as well as managing cryptographic keys. During a transaction, the wallet digitally signs the transaction using a private key-based digital signature to authenticate the transaction. In order to meet the requirements of our project Crypto Processor, we have decided to only employ Multi-Party Computation (MPC) wallets since they provide some special advantages and new features, including the following:

• Next-Generation Design: MPC wallets represent a next-generation form compared to traditional multisignature (multisig) wallets, with improved security and efficiency of operation.

• Off-Chain Functionality: MPC wallets are optimized to operate off-chain, i.e., their computations take place outside of any blockchain framework, reducing the reliance on on-chain infrastructure.

• Protocol Independence: MPC wallets are not protocol-specific, meaning that they can be utilized with a wide range of cryptographic frameworks and applications.

• Cost Efficiency: Because they transact off-chain, they eliminate additional transaction charges that are normally part of blockchain-based activity, such as in the case of multisig arrangements.

• Fragmented Key Creation: The private key is never generated in full even while being generated. Rather, it is divided into many fragments such that it is never whole at any given time.

• Distributed Security: The key components are divided and placed on at least three machines (e.g., servers, phones, or other endpoints) and are never combined onto a single machine. This distributed approach enhances security by eliminating one point of compromise.

• Flexible Signing Thresholds: Not all key fragments need to participate in signing a transaction. For example, a threshold system may allow any 3 out of 4 fragments to sign, providing both resilience and convenience.

• Quorum Flexibility: The signing quorum can be modified without generating new addresses, making key management more convenient than in conventional methods.

• Key Refresh Support: MPC wallets offer key fragment refresh support at regular intervals, which allows the cryptographic material to be re-refreshed without affecting the respective address or compromising security.

By adopting MPC wallets, our project Crypto Processor enjoys the benefits of a cutting-edge solution that combines high security with operational flexibility. Distributed key construction and off-chain functionality make these wallets ideal for modern-day cryptographic use cases, ensuring better protection and flexibility across a broad spectrum of use cases.

Figure 1: How to MPC wallets works. Source: cointelegraph.com

Modern Web3 Wallets: Authentication Standards and Use Cases

Web3 wallets have been driven by demand for secure, user-friendly authentication methods that combine Web2 usability with the decentralization ethos of Web3. Modern standards like WebAuthn, Secure Enclave, and Passkeys are increasingly being integrated into Web3 wallets to enhance security and usability. A comprehensive analysis from a Mirror blog post looks into how these technologies are being used across various wallet implementations, accompanied by a corresponding diagram detailing their usage.

Authentication Standards

1. Secure Enclave (Trusted Execution Environment - TEE)

• Definition: A Secure Enclave is a hardware-isolated subsystem within a device that is utilized to protect confidential information like private keys. As an instance of TEE, it ensures that cryptographic operations occur within an un-tamperable area inaccessible to the device's general operating system or third-party applications.

• Role in Web3 Wallets: Secure Enclaves store and manage private keys, performing signing without exposing the key to potential malware or unauthorized actors.

2. WebAuthn

• Definition: WebAuthn is a W3C-standardized passwordless authentication protocol supporting users to authenticate themselves through public-key cryptography. The user's public key is retained on the platform (e.g., a wallet), and during login, sends a challenge (a message) that the user signs using their private key. The private key is typically protected by a PIN, biometric authentication (e.g., Face ID), or a hardware security module, typically located in a Secure Enclave.

• Security: WebAuthn stores the user's private key on their device, reducing the risk of phishing or server-side breach.

3. Passkey

• Definition: A Passkey is an implementation of WebAuthn that enhances cross-device ease. The user's encrypted private key is stored in the cloud and can be synced across devices with security ensured through the use of device-bound authentication (e.g., biometrics).

• Benefit: Passkeys eliminate seed phrases, giving the hassle-free experience of Web2 logins while keeping Web3 non-custodial.

Smart Contract Accounts

• Definition: Smart Contract Accounts (SCAs) are code-governed blockchain accounts rather than one private key, often implemented as multisig wallets. They enable programmable logic for transaction validation, recovery, and automation, typically enforced through standards like ERC-4337 (account abstraction).

• Benefits: SCAs facilitate richer features like social recovery, gasless transfers, and custom authentication schemes, which confer greater flexibility than Externally Owned Accounts (EOAs).

Algorithms for Creating MPC Wallets

In developing and designing Multi-Party Computation (MPC) wallets, we studied different algorithms that each had different approaches to key generation, distribution, and reconstruction. Below are the algorithms we studied, along with their main characteristics.

1. Shamir's Secret Sharing (SSS)

Shamir's Secret Sharing is a protocol that divides a secret (in our example, the private key) into several shares, of which only a predetermined number of shares, considered as the threshold, are needed to restore the original secret. This threshold offers flexibility in key management, as it ensures not all shares are mandatory. Shareholders have no access to the other shares or the complete key. SSS has encrypted the secret into a polynomial and the secret is normally the constant term. Shares are then calculated as points on the polynomial and distributed to participants. Reconstruction arises by means of polynomial interpolation, such as Lagrange interpolation, from the threshold shares. But one major disadvantage is that the secret can be revealed in the process of reconstruction if not handled securely, offering a potential vulnerability. Another major disadvantage is that Shamir’s Secret Sharing assumes the dealer honestly generates and distributes valid shares without leaking the secret.

Figure 2: Illustration of the Shamir's Secret Sharing (SSS) algorithm for the private key 7 using the polynomial function $f(x) = 7 + 2x + 3x^2 \; mod \; 11$

Algorithm Steps

1. Define Parameters

• Determine the secret $S$ (e.g., a number you want to share).
• Choose a threshold $t$, the minimum number of shares required to reconstruct the secret.
• Select the number of shares $n$, where $n \geq t$, representing the total number of shares to be created.
• Pick a prime number $p$ (larger than $S$ and $n$), as computations are performed in the finite field $\mathbb{GF}(p)$.

2. Create a Polynomial

Construct a polynomial of degree $t - 1$:

$$f(x) = S + a_1x + a_2x^2 + \dots + a_{t-1}x^{t-1} \mod p$$

Where:

• $S$ is the constant term (the secret),
• $a_1, a_2, \dots, a_{t-1}$ are random coefficients chosen from the set $\{0, 1, \dots, p - 1\}$.

3. Generate Shares

• Choose $n$ distinct values for $x$, typically $x = 1, 2, \dots, n$.
• Compute the polynomial values $f(x_i)$ for each $x_i$:

$$y_i = f(x_i) \mod p$$

• The resulting pairs $(x_i, y_i)$ are the shares of the secret.

4. Distribute Shares

• Distribute the pairs $(x_i, y_i)$ to $n$ participants, with each participant receiving one unique pair.

5. Reconstruct the Secret

• When at least $t$ shares $(x_i, y_i)$ are collected, use Lagrange interpolation to reconstruct the polynomial $f(x)$.

The interpolation formula is:

$$f(x) = \sum_{i=1}^{t} y_i \cdot \ell_i(x) \mod p$$

Where:

$$\ell_i(x) = \prod_{\substack{1 \leq j \leq t \\ j \neq i}} \frac{x - x_j}{x_i - x_j}$$

• The secret $S$ is the value of the polynomial at $x = 0$:

$$S = f(0)$$

Note

• If fewer than $t$ shares are available, the secret cannot be reconstructed.
• All computations are performed using modular arithmetic modulo $p$, ensuring security within the finite field.

2. Publicly Verifiable Secret Sharing (PVSS)

PVSS is a more mature form of SSS that incorporates the introduction of a receiver user into the process. Compared to SSS, in which the participants are compelled to reveal their shares to reconstruct, PVSS enhances privacy using ElGamal encryption. Participants encrypt their share and send it to a receiver who can reconstruct the secret without the participants divulging their individual shares. Furthermore, PVSS allows verification of the shares by the public without revealing the secret. It is therefore suitable for uses requiring transparency and auditability but not secrecy.

Figure 3: Illustration of the Publicly Verifiable Secret Sharing (PVSS) algorithm for the private key 7 using the polynomial function $f(x) = 7 + 2x + 3x^2 \; mod \; 11$

Algorithm Steps

1. Setup Parameters

• Define the secret $S$ (e.g., a number or cryptographic value to be shared).
• Choose a threshold $t$, the minimum number of shares required to reconstruct the secret.
• Select the number of participants $n$, where $n \geq t$, representing the total number of shares.
• Use a finite field $\mathbb{GF}(p)$, where $p$ is a large prime number.
• Establish a public-key cryptosystem (e.g., based on discrete logarithms or elliptic curves) with:
  • A cyclic group $G$ of order $q$ (a large prime).
  • A generator $g \in G$.
  • Each participant $i$ has:
    • A public key $Y_i = g^{x_i}$
    • A private key $x_i$

2. Create a Polynomial and Encrypt Shares

• Construct a random polynomial of degree $t - 1$:

$$f(x) = S + a_1x + a_2x^2 + \dots + a_{t-1}x^{t-1} \mod q$$

Where:

• $S$ is the secret

• $a_1, a_2, \dots, a_{t-1}$ are random coefficients in $\{0, 1, \dots, q - 1\}$

• Compute a share for each participant $i$:

$$s_i = f(i) \mod q$$

• Encrypt each share $s_i$ using participant $i$’s public key $Y_i$:

$$E_i = g^{s_i} \cdot Y_i$$

(This ensures only participant $i$ with private key $x_i$ can decrypt their share.)

3. Generate Public Commitments

• For each coefficient $a_j$ (including the secret $S = a_0$), compute a commitment:

$$C_j = g^{a_j}, \quad \text{for } j = 0, 1, \dots, t - 1$$

• These commitments are published to allow public verification of shares without revealing the secret.

4. Distribute Shares and Publish Data

• Send each encrypted share $E_i$ to participant $i$.

• Publish:

  • The commitments $C_0, C_1, \dots, C_{t-1}$
  • The encrypted shares $E_1, E_2, \dots, E_n$

• Each participant $i$ can decrypt their share $s_i$ using their private key $x_i$:

$$s_i = \frac{E_i}{Y_i^{x_i}} \mod q$$

5. Public Verification

Anyone can verify the validity of encrypted shares without knowing the secret.

• For each participant $i$, verify that the encrypted share $E_i$ corresponds to the committed polynomial using:

$$E_i \stackrel{?}{=} g^{f(i)} \cdot Y_i$$

Where $g^{f(i)}$ is reconstructed from the commitments:

$$g^{f(i)} = C_0 \cdot C_1^i \cdot C_2^{i^2} \cdots C_{t-1}^{i^{t-1}}$$

If the equation holds, the share is valid.

6. Reconstruct the Secret

• Collect at least $t$ valid shares $s_i = f(i)$ from participants.
• Use Lagrange interpolation over $\mathbb{GF}(q)$ to reconstruct the polynomial $f(x)$:

$$f(x) = \sum_{i \in T} s_i \cdot \ell_i(x) \mod q$$

Where:

• $T$ is the set of $t$ participants
• $\ell_i(x)$ is the Lagrange basis polynomial:

$$\ell_i(x) = \prod_{\substack{j \in T \\ j \ne i}} \frac{x - j}{i - j}$$

• The secret is the constant term of the polynomial:

$$S = f(0)$$

3. Verifiable Secret Sharing (VSS)

VSS is an improved version of the SSS protocol that is more secure and friendly to distributed systems, particularly concerning Distributed Key Generation (DKG). VSS enhances security by enabling participants to verify their shares’ correctness, preventing dishonest dealers from distributing invalid or inconsistent shares. This approach makes VSS an appropriate solution for cooperative key management in MPC setups. Unlike Publicly Verifiable Secret Sharing (PVSS), VSS typically requires participants to verify their own shares (not necessarily publicly verifiable to outsiders). In case a share is erroneous, participants can initiate a dispute resolution protocol (depending on the scheme).

Figure 4: Illustration of the Verifiable Secret Sharing (VSS) algorithm for the private key 7 using the polynomial function $f(x) = 7 + 2x + 3x^2 \; mod \; 11$

Algorithm Steps

1. Setup Parameters

• Define the secret $S$ (e.g., a number to be shared).
• Choose a threshold $t$, the minimum number of shares required to reconstruct the secret.
• Select the number of participants $n$, where $n \geq t$, representing the total number of shares.
• Use a finite field $\mathbb{GF}(q)$, where $q$ is a large prime.
• Choose a cyclic group $G$ of order $q$ with a generator $g$, where the discrete logarithm problem is hard (e.g., in elliptic curves or modular arithmetic).

2. Create a Polynomial

Construct a random polynomial of degree $(t - 1)$:

$$f(x) = S + a_1x + a_2x^2 + \dots + a_{t-1}x^{t-1} \mod q$$

Where:

• $S$ is the secret (the constant term),
• $a_1, a_2, \dots, a_{t-1}$ are random coefficients from $\{0, 1, \dots, q - 1\}$.

3. Generate Shares

For each participant $i$ (where $i = 1, 2, \dots, n$), compute the share:

$$s_i = f(i) \mod q$$

Each $s_i$ is a share of the secret.

4. Create Commitments

For each coefficient $a_j$ (including the secret $S = a_0$), compute a commitment:

$$C_j = g^{a_j}, \quad \text{for } j = 0, 1, \dots, t - 1$$

Specifically, the commitment to the secret is:

$$C_0 = g^S$$

These commitments are broadcast to all participants.

5. Distribute Shares and Commitments

• Send each share $s_i$ to participant $i$ securely (e.g., via encrypted channels).
• Broadcast the commitments $C_0, C_1, \dots, C_{t-1}$ to all participants.

6. Verify Shares

Each participant $i$ verifies the correctness of their share $s_i$:

• Compute the expected value of $g^{f(i)}$ using the commitments:

$$g^{f(i)} = C_0 \cdot C_1^i \cdot C_2^{i^2} \cdots C_{t-1}^{i^{t-1}}$$

• Check the equality:

$$g^{s_i} \stackrel{?}{=} g^{f(i)}$$

If the equation holds, the share $s_i$ is valid. Otherwise, the participant can raise a complaint about an invalid share.

7. Reconstruct the Secret

• Collect at least $t$ valid shares $s_i = f(i)$ from participants.
• Use Lagrange interpolation to reconstruct the polynomial $f(x)$:

$$f(x) = \sum_{i \in T} s_i \cdot \ell_i(x) \mod q$$

Where $T$ is the set of $t$ participants and:

$$\ell_i(x) = \prod_{\substack{j \in T \\ j \ne i}} \frac{x - j}{i - j}$$

• The secret is the constant term of the polynomial:

$$S = f(0)$$

4. Distributed Key Generation (DKG)

DKG is a family of algorithms that enables the distributed key process generation among numerous parties. Unlike centralized key generation, DKG ensures that no single participant ever possesses the complete key at any point in time. Instead, each participant independently derives a segment of the key, and the final key is implicitly generated through cryptographic collaboration. DKG is usually coupled with protocols such as VSS to offer security and verifiability. It is especially useful for MPC wallets because it supports the objective of removing single points of failure and ensuring key fragmentation over the wallet's life cycle. The protocol utilizes a synchronous model of communication and may include dispute-resolution or malicious participant-handling mechanisms. DKG is often applied in threshold cryptography, such as distributed signature schemes (e.g., ECDSA) or encryption schemes. In the event that a participant is deemed unqualified, due to non-compliance, misbehavior, or invalid contributions, the protocol may either be repeated or proceed with the remaining qualified participants.

Figure 5: Illustration of the Distributed key generation (DKG) algorithm for the private key 7 using the polynomial function $f(x) = 7 + 2x + 3x^2 \; mod \; 11$

Algorithm Steps

1. Setup Parameters

• Define the number of participants $n$ and the threshold $t$, where $t \leq n$, such that at least $t$ participants are needed to reconstruct the private key or perform cryptographic operations.
• Use a finite field $\mathbb{GF}(q)$, where $q$ is a large prime.
• Choose a cyclic group $G$ of order $q$ with a generator $g$, where the discrete logarithm problem is hard (e.g., in elliptic curves or modular arithmetic).
• Each participant $P_i$ (for $i = 1, 2, \dots, n$) will contribute to generating the key pair.

2. Individual Secret Sharing by Each Participant

Each participant $P_i$ independently:

• Chooses a random secret $s_i \in \mathbb{Z}_q$ (their contribution to the private key).
• Constructs a random polynomial of degree $t - 1$:

$$f_i(x) = s_i + a_{i,1}x + a_{i,2}x^2 + \dots + a_{i,t-1}x^{t-1} \mod q$$

Where $a_{i,1}, a_{i,2}, \dots, a_{i,t-1}$ are random coefficients in $\mathbb{Z}_q$.

• Computes shares for all participants:

$$s_{i,j} = f_i(j) \mod q, \quad \text{for } j = 1, 2, \dots, n$$

• Generates commitments for the polynomial coefficients:

$$C_{i,k} = g^{a_{i,k}}, \quad \text{for } k = 0, 1, \dots, t-1$$

Where $a_{i,0} = s_i$, so $C_{i,0} = g^{s_i}$ is the commitment to the secret.

3. Distribute Shares and Commitments

Each participant $P_i$:

• Securely sends share $s_{i,j}$ to participant $P_j$ (e.g., via encrypted channels).
• Broadcasts the commitments $C_{i,0}, C_{i,1}, \dots, C_{i,t-1}$ to all participants.

4. Verify Received Shares

Each participant $P_j$ verifies the shares they received from other participants $P_i$:

• For each share $s_{i,j}$ from $P_i$, check if:

$$g^{s_{i,j}} \stackrel{?}{=} C_{i,0} \cdot C_{i,1}^j \cdot C_{i,2}^{j^2} \cdots C_{i,t-1}^{j^{t-1}}$$

• If the equation holds, the share $s_{i,j}$ is valid; otherwise, $P_j$ raises a complaint against $P_i$.
• If a participant receives too many complaints or fails to provide valid shares, they may be disqualified (depending on the protocol).

5. Compute the Global Private and Public Keys

Each participant $P_j$ computes their share of the global private key by summing the valid shares they received:

$$x_j = \sum_{i \in Q} s_{i,j} \mod q$$

Where $Q$ is the set of qualified (honest) participants who provided valid shares.

• The global private key $x$ (which is never explicitly reconstructed) is implicitly:

$$x = \sum_{i \in Q} s_i \mod q$$

• The global public key $y$ is computed by combining the commitments:

$$y = \prod_{i \in Q} C_{i,0} = \prod_{i \in Q} g^{s_i} = g^x$$

Each participant can compute $y$ using the broadcasted $C_{i,0}$ values.

6. Output

Each participant $P_j$ holds:

• Their share $x_j$ of the global private key
• The global public key $y$

The private key $x$ is never explicitly known to any single participant, but can be used implicitly through threshold operations (e.g., signing or decryption) by combining $t$ or more shares.

Summary

These algorithms collectively address the core requirements of MPC wallets: secure key distribution, resilience against compromise, and operational efficiency. The choice of algorithm depends on specific use-case needs, such as the desired threshold, the level of verifiability, and the complexity of participant interactions. Each approach presents trade-offs: Shamir’s Secret Sharing (SSS) offers simplicity, Verifiable Secret Sharing (VSS) ensures the integrity of distributed shares, Publicly Verifiable Secret Sharing (PVSS) adds public auditability, and Distributed Key Generation (DKG) enables fully decentralized key creation. These options allow us to tailor the MPC wallet architecture to meet both security and performance goals.